1. Field of the Invention
The present invention relates to a method for co-verifying hardware and software to be mounted on a semiconductor device.
2. Description of the Related Art
In recent years, apparatuses equipped with SoCs have been spreading widely. SoC is an acronym for System on a Chip, and refers to a technology for packing the core functions of a computer onto a single chip (semiconductor device) or refers to the chip itself on which the core functions of a computer are integrated using the SoC technology.
FIG. 1 shows an upstream design flow for such a SoC. As shown, after completing the design at the system level, the process proceeds to the design at the architecture level. In the architecture-level design, the selection of basic components, such as a CPU (Central Processing Unit), OS (Operating System), bus, etc., the division of functions between hardware and software, and hardware and software designs are performed. Then, for the basic components, hardware components, and software components obtained from the architecture-level design, hardware/software co-verification is performed using verification models.
Generally, in such hardware/software co-verification, an ISS (Instruction Set Simulator) which performs simulation at the instruction level is used as the verification model for the CPU, as disclosed in patent documents 1 to 3 given below. The ISS is written using a C-based language; System-G (produced by GAIO Technology), etc. is a known example of a commercially available simulator. In this specification, the “C-based language” refers to one of various extended ANSI-C/C++ languages or, more specifically, either SpecC or SystemC.
Verification models written in the C-based language are also used for hardware components such as a CPU dedicated memory, bus, etc. For other hardware components, verification models based on a behavioral description or an RTL (Register Transfer Level) description, created using the C-based language, are used. The behavioral description is one that describes circuit behavior, while the RTL description is one that describes how register values change.
On the other hand, verification models for software components, such as the OS, middleware, interrupt handler, device drivers, tasks, etc., are constructed using the real logic, i.e., the binary code (instruction code) itself, for the target CPU. In this specification, the “target CPU” refers to the CPU (for example, an ARM processor) mounted on a semiconductor device, such as an SoC, to be verified.
By adding a testbench and a C-based simulator to the above verification models (software components and hardware components), a prior art co-verification system (software configuration) such as shown in FIG. 2 is constructed. The testbench performs operations such as a test data input, test data output, comparisons with expected values, etc., while the C-based simulator controls the entire operation of the simulation. The ISS operates by accepting a maskable interrupt INT (maskable INTerrupt) from a hardware component or a nonmaskable interrupt NMI (NonMaskable Interrupt) from the testbench.
The ISS provides the functions of instruction-level simulation, memory access (load/store instruction), I/O access, and interrupt processing. The instruction-level simulation function executes simulation at the binary code level of the target CPU. The memory access function executes a read/write access to the bus. Here, the bus controls the memory access. The I/O access function executes a read/write access to the bus using a load/store instruction (the amount of data transfer per instruction is small). Here, the bus controls the I/O (hardware component) access. The interrupt processing function executes such operations as accepting an interrupt (INTi (i=1, . . . , n), NMI), controlling the activation of the interrupt handler, interrupting the processing being performed, and resuming the interrupted processing.
Prior art literature concerning co-verification using an ISS includes non-patent documents 1 and 2 shown below as well as the patent documents 1 to 3. Non-patent document 3 listed below concerns a “Basic Block” which will be cited in the description given later in this specification, non-patent documents 4 to 6 concern a “Fixed I/O Behavioral Model” which will be cited in the description given later in this specification, and non-patent documents 7 to 9 concern technical trends in design and verification based on the C language.
(Patent Document 1) Japanese Unexamined Patent Publication No. 2000-259445
(Patent Document 2) Japanese Unexamined Patent Publication No. 2001-256072
(Patent Document 3) Japanese Unexamined Patent Publication No. 2002-175344
(Non-patent Document 1) Kazutoshi Wakabayashi, “LSI Design and Behavioral Synthesis using C Language and Methodology for HW/SW Co-verification,” NE Embedded Symposium 2002.
(Non-patent Document 2) Kurokawa, Ikegami, Ootsubo, Asao, Kirigaya, Misu, Takahashi, Kawatsu, Nitta, Kasa, Wakabayashi, Tomobe, Takahashi, Mukaiyama, and Takenaka, “Analysis and Study on Effectiveness of System LSI Design Methodology using C-Language-Based Behavioral Synthesis,” IEICE 15th Karuizawa Workshop, pp. 131–142, April 2002.
(Non-patent Document 3) T. Sherwood, E. Perelman, and B. Calder, “Basic Block Distribution Analysis to Find Periodic Behavior and Simulation Points in Applications,” in International Conference on Parallel Architectures and Compilation Techniques, September 2001.
(Non-patent Document 4) D. W. Knapp, T. Ly, D. MacMillen, and R. Miller, “Behavioral Synthesis Methodology for HDL-Based Specification and Validation,” Proc. Design Automation Conf., June 1995.
(Non-patent Document 5) T. Ly, D. W. Knapp, R. Miller, and D. MacMillen, “Scheduling using Behavioral Templates,” Proc. Design Automation Conf., June 1995.
(Non-patent Document 6) D. W. Knapp, “Behavioral Synthesis: Digital System Design using the Synopsis Behavioral Compiler,” Prentice Hall PTR.
(Non-patent Document 7) L. Gauthier, S. Yoo, and A. A. Jerraya, “Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software,” Proc. Design Automation and Test in Europe, March 2001.
(Non-patent Document 8) D. Lyonnard, S. Yoo, A. Baghdadi, and A. A. Jerraya, “Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System-on-Chip,” Proc. Design Automation Conf., June 2001.
(Non-patent Document 9) S. Yoo, G. Nicolescu, L. Gauthier, and A. A. Jerraya, “Automatic Generation of Fast Timed Simulation Models for Operating Systems in SoC,” Proc. Design Automation and Test in Europe, March 2002.
In the hardware/software co-verification methods using ISSs according to the prior art described above, as simulation is performed at the instruction level, that is, simulation is performed on an instruction-by-instruction basis by interpreting the contents of each instruction, which requires a memory access, the prior art involves the problem that the simulation time, i.e., the verification time, increases.